home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 906 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: kanze@gabi-soft.fr (J. Kanze)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Rationale behind disallowal of non-const reference to rvalue
  5. Followup-To: comp.std.c++
  6. Date: 29 Mar 1996 16:09:56 GMT
  7. Organization: GABI Software, Sarl.
  8. Approved: clamage@eng.sun.com (comp.std.c++)
  9. Message-ID: <KANZE.96Mar29121910@gabi.gabi-soft.fr>
  10. References: <DAVEW.96Mar27195129@trigati.cs.haverford.edu>
  11. NNTP-Posting-Host: taumet.eng.sun.com
  12. X-Nntp-Posting-Host: gabi.gabi-soft.fr
  13. In-Reply-To: davew@trigati.cs.haverford.edu's message of 28 Mar 1996 09:35:40 PST
  14. Content-Length: 2372
  15. X-Lines: 53
  16. Originator: clamage@taumet
  17.  
  18. In article <DAVEW.96Mar27195129@trigati.cs.haverford.edu>
  19. davew@trigati.cs.haverford.edu (David G. Wonnacott) writes:
  20.  
  21. |> I am looking for an explanation for the rationale behind the decision
  22. |> of the standards committee to disallow the binding of a non-const
  23. |> reference to an rvalue.  I assume this has been discussed to death
  24. |> here before, but I haven't been able to find it in a FAQ; I'd be happy
  25. |> with a reference to another document rather than a full reply here.
  26.  
  27. First: it wasn't the committee's decision (except in so far as they
  28. didn't change the base document).  This was illegal in the ARM.
  29.  
  30. Consider the following:
  31.  
  32.     void
  33.     incr( int& i )
  34.     {
  35.         i ++ ;
  36.     }
  37.  
  38.     unsigned        j = 1 ;
  39.     incr( j ) ;
  40.  
  41. Without the rule, the above is perfectly legal code.  However, the call
  42. to `incr' does *NOT* modify `j', as the programmer probably expected it
  43. would.  The reason is that incr takes an int, not an unsigned.  The
  44. compiler implicitly converts, but the result of this conversion is not
  45. an lvalue, but a temporary, and it is the temporary that gets bound to
  46. the reference parameter.
  47.  
  48. I don't know when this rule was introduced, but it has been present in
  49. all C++ texts I've seen except the first edition of Stroustrup (1986).
  50. (Note that the exact example above appears on page 86 of _The Design_
  51. _and_Evolution_of_C++.  Given that this was originally allowed, and that
  52. actual practical experience found it to be a mistake, it was hardly
  53. likely that the committee would undo it.)
  54.  
  55. There have been suggestions that only implicit conversions should be
  56. banned, and not all rvalues.  However, as far as I know, no one ever
  57. came up with a concrete proposal along these lines, and I believe that
  58. the standard is too far advanced now to make the change (although it
  59. sure would simplify the problems with auto_ptr:-).
  60.  
  61. |> The only answer I've seen for this question before is that it is
  62. |> disallowed because the reference may outlive the rvalue it refers to.
  63.  
  64. If you want to know why certain features are (or are not) in C++, you
  65. should definitly read the above mentioned book.
  66. -- 
  67. James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
  68. GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
  69. Conseils en informatique industrielle --
  70.                             -- Beratung in industrieller Datenverarbeitung
  71.  
  72.  
  73. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  74. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  75. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  76. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  77. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  78.